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STRESZCZENIE 


Technologia radia programowalnego (Software Defined Radio) jest nowoczesnym rozwia- 
zaniem umożliwiającym realizację urządzeń pracujących w różnego rodzaju systemach łączności 
radiowej, zarówno cywilnych, jak i wojskowych. W artykule zaprezentowano zagadnienia dotyczące 
koncepcji realizacji radia programowalnego. Opisano w sposób funkcjonalny platformę sprzętową 
i programową takiego rozwiązania. Zaprezentowano budowę przykładowej platformy sprzętowej do 
realizacji radia programowalnego. Przedstawiono również architekturę oprogramowania używaną 
w systemie dla zastosowań wojskowych o nazwie Joint Tactical Radio System (JTRS). 
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WSTĘP 


Wraz z rozwojem systemów cyfrowej radiokomunikacji ruchomej istnieje 
potrzeba nieustannego opracowywania nowych rozwiązań terminali ruchomych, 
które mogłyby sprostać zapotrzebowaniu użytkowników na nowe usługi transmisji 
danych o dużych przepływnościach. Ponadto różnorodność standardów systemów 
cywilnych i wojskowych przy dużej mobilności ich użytkowników powoduje, że 
pożądane jest opracowanie wielosystemowego terminala ruchomego, zdolnego do 
współpracy z systemami radiokomunikacyjnymi działającymi w różnych standardach 
i zapewniającego bezpieczeństwo kryptograficzne transmisji. Stało się to powodem 
podjęcia prac nad koncepcją realizacji radia programowalnego (SDR — Software 
Defined Radio), której celem jest zastąpienie członów nadawczo-odbiorczych, reali- 
zowanych sprzętowo, w jednym standardzie, przez możliwie uniwersalny hardware, 
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w którym występują człony wielkiej częstotliwości nadajnika i odbiornika, szeroko- 
pasmowe przetworniki C/A i A/C i procesor sygnałowy oraz inne układy programo- 
walne [9, 10]. Wówczas funkcje nadawczo-odbiorcze mogą być głównie realizowane 
programowo przez procesor sygnałowy [1, 8]. 


ARCHITEKTURA PROGRAMOWALNEGO TERMINALA RUCHOMEGO 


Architekturę programowalnego terminala ruchomego można ogólnie przedsta- 
wić jak na rysunku 1., przy czym symbol komputera reprezentuje źródło i/lub obiekt 
przeznaczenia dowolnych sygnałów cyfrowych z pominięciem sygnałów mowy [8]. 
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Rys. 1. Ogólna architektura programowalnego terminala ruchomego 


Duplekser 


Źródło: J. Stefański, S. Gajewski, A. Marczak, Radio rekonfigurowalne programowo w systemie 
UMCS, „Elektronik”, 2001, nr 11. 


Jak widać na rysunku, analogowy wzmacniacz mocy i filtr pasmowo- 
-przepustowy w nadajniku poprzedza przetwornik C/A, do którego są dostarczane 
sygnały cyfrowe z bloku cyfrowego przetwarzania sygnałów, w którym są realizo- 
wane między innymi funkcje kodowania i modulacji, a niskoszumny wzmacniacz 
wejściowy i filtr pasmowo-przepustowy w odbiorniku przekazują analogowe sygnały 
odebrane poprzez przetwornik A/C do tego samego bloku cyfrowego przetwarzania 
sygnałów, między innymi w celu detekcji i dekodowania. Taka realizacja terminala 
programowalnego przy współczesnym poziomie rozwoju technologicznego jest na 
razie niewykonalna [9, 10]. Ograniczenia te wynikają przede wszystkim z braku 
przetworników A/C i C/A o wymaganej szybkości i dynamice przetwarzania oraz 
ograniczonej szybkości przetwarzania dostępnych procesorów sygnałowych. W tej 
sytuacji obiecująca wydaje się architektura, w której przetwarzanie A/C i C/A odbywa 
się w paśmie pośredniej częstotliwości, co zostało przedstawione na rysunku 2. [2]. 
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Rys. 2. Architektura terminala programowalnego z przetwarzaniem A/C i C/A 
w członie pośredniej częstotliwości 


== 


Źródło: A. Marczak, R. J. Katulski, J. Stefański, Technika radia programowalnego, „Przegląd 


Telekomunikacyjny”, 2004, nr 10. 


Blok cyfrowego przetwarzania sygnałów w terminalu programowalnym po- 


winien realizować następujące funkcje toru nadawczo-odbiorczego [9]: 


— obsługi interfejsu użytkownika; 

— kodowanie i dekodowanie źródłowe; 
— kodowanie i dekodowanie kanałowe; 
— szyfracje i deszyfrację; 

— przeplot i rozplot bitowo-blokowy; 
— cyfrową filtrację sygnału; 

— modulację i demodulację; 

— synchronizację. 


W przypadku zastosowania w interfejsie radiowym bezpośredniego rozpra- 


szania widma blok cyfrowego przetwarzania sygnałów powinien dodatkowo reali- 


zować następujące funkcje: 


— ortogonalizacje i deortogonalizację sygnałów; 
— rozpraszanie i skupianie widma sygnałów; 
— dynamiczne sterowanie mocą sygnałów wyjściowych; 


— odbiór wielodrogowy i wspólny sygnałów wielu użytkowników (multi-user 


detection). 
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ARCHITEKTURA OPROGRAMOWANIA 


Na tle ogólnej architektury programowalnego terminala ruchomego wydaje się 
celowe wydzielenie bardziej szczegółowej architektury oprogramowania takiego termi- 
nala. Niestety do tej pory nie jest znana żadna architektura tego rodzaju oprogramo- 
wania dla zastosowań cywilnych. Istnieje natomiast architektura oprogramowania 
terminala ruchomego dla zastosowań wojskowych. Nazywa się ona programową 
architekturą komunikacyjną SCA (Sofiware Communication Architecture) [6] i zo- 
stała przygotowana oraz opublikowana przez biuro JPO (Joint Program Office) armii 
Stanów Zjednoczonych w ramach prac nad wspólnym taktycznym systemem radiowym 
JTRS (Joint Tactical Radio System). Biuro JPO zostało bowiem powołane w celu koor- 
dynowania prac nad rozwojem przyszłych wojskowych systemów telekomunikacyj- 
nych, z uwagi na postęp technologiczny, który miał miejsce w ostatnich latach. 
Rozwój tych systemów ma na celu poprawę współpracy różnych nowoczesnych syste- 
mów łączności oraz redukcję kosztów ich modernizacji i rozwoju. Do podstawowych 
celów programu JTRS należy zwiększenie elastyczności i poprawy współdziałania sys- 
temów projektowanych przez różnych producentów oraz redukcja późniejszych 
kosztów utrzymania posiadanych rozwiązań. 

Architektura SCA ma zapewniać przenośność aplikacji pomiędzy imple- 
mentacjami SCA różnych producentów oraz umożliwiać redukcję kosztów i czasu 
projektowania systemów poprzez możliwości wielokrotnego wykorzystania zapro- 
jektowanych wcześniej modułów oprogramowania, a także ułatwiać późniejsze, 
ewolucyjne zmiany struktury oprogramowania [4, 6]. Architektura SCA jest z zało- 
żenia opracowana w celu zaspokojenia wymagań spodziewanych w odniesieniu do 
aplikacji wojskowych, jednak oczekuje się, że zostanie ona także uznana za standard 
komercyjny i będzie również wykorzystywana w cywilnych systemach radia pro- 
gramowalnego. Powodem tego jest fakt, że liczne, wiodące w świecie firmy zostały 
zaproszone do wspólnego opracowania standardu architektury SCA, który nie jest 
specyfikacją systemu, ale zbiorem zasad i reguł wytyczających projektowanie sys- 
temu w celu osiągnięcia podanych wyżej celów. Dokumentacja SCA zawiera więc 
podstawową specyfikację architektury oprogramowania, suplement dotyczący bezpie- 
czeństwa, zasady tworzenia interfejsów aplikacji API (Application Program Interface) 
oraz dokumenty uzasadniające [6]. 

Struktura oprogramowania SCA definiuje środowisko programowe i specyfi- 
kuje usługi oraz interfejsy, których używają aplikacje. Środowisko programowe skła- 
da się przy tym z systemu operacyjnego czasu rzeczywistego, struktury rdzeniowej 
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(Core Framework) i oprogramowania posredniczacego CORBA (Common Object 
Request Broker Architecture) (3, 6], służąc do komunikacji obiektów rozproszo- 
nych. Podstawowym celem oprogramowania CORBA jest umozliwienie komunika- 
cji między odległymi i niekompatybilnymi systemami pracującymi na różnych 
platformach sprzętowych i programowych. Architektura oprogramowania CORBA 
pozwala uprościć proces tworzenia aplikacji rozproszonych w Internecie oraz w sie- 
ciach korzystających z wielu różnych protokołów [5]. Oprogramowanie CORBA 
wykonuje funkcje realizujące połączenia między obiektami dostarczającymi usługi 
a obiektami korzystającymi z nich. Elastyczność tej technologii umożliwia stosowanie 
dowolnych protokołów komunikacyjnych, korzystanie z dowolnej platformy syste- 
mowej oraz posługiwanie się praktycznie każdym językiem programowania [6]. 

Środowisko programowe narzuca ograniczenia projektowe na aplikacje dla 
zapewnienia większej przenośności z platform programowych zgodnych z architek- 
turą SCA do innych platform. Polegają one na wykorzystaniu specyficznych inter- 
fejsów pomiędzy strukturą szkieletową i aplikacjami oraz ograniczeniu wykorzystania 
systemu operacyjnego. Architektura SCA określa ponadto moduły funkcjonalne 
zdefiniowane w suplemencie API. Definiują one interfejsy programowe pomiędzy 
różnymi zbiorami funkcji określającymi aplikacje. Takie moduły ułatwiają wielokrot- 
ne wykorzystywanie tych zbiorów funkcji i sprzyjają elastyczności projektowania [6]. 

Struktura szkieletowa architektury jest koncepcją wyznaczającą rdzeń zło- 
żony z otwartych programowych interfejsów i profili, które realizują operacje roz- 
mieszczenia, zarządzania i komunikacji pomiędzy zbiorami funkcji wyznaczających 
aplikacje w systemie łączności opartym na przetwarzaniu rozproszonym. Ponadto 
część interfejsów może być wykorzystana przez aplikacje nienależące do struktury 
szkieletowej oraz przez producentów sprzętu. Struktura szkieletowa tworzy więc 
bazę danych na podstawie zbioru profili znanych jako domena profili (Domain Profile) 
i dostarcza ją do użytkowania w systemie [6]. 

Nowością w tym rozwiązaniu jest użycie koncepcji zorientowanej obiektowo, 
również w opisie struktury sprzętowej. Koncepcja ta, wykorzystywana dotychczas 
w projektowaniu oprogramowania, została zastosowana do zdefiniowania bloków 
sprzętowych realizowanego systemu. Pierwotnym celem takiego podejścia do struk- 
tury sprzętowej była potrzeba wszechstronnego określenia i opisania interfejsów 
oraz atrybutów poszczególnych sprzętowych elementów systemu. Zgodnie z tymi 
opisami producenci sprzętu mogą dostarczać dodatkowe moduły, a projektanci 
oprogramowania identyfikować moduły sprzętowe o konkretnych właściwościach 
dla określonych aplikacji [6]. 
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Architektura SCA definiuje część programową i sprzętową na różnych po- 
ziomach hierarchii i precyzuje szerokie możliwości wielokrotnego wykorzystania 
i przenośności oprogramowania. Część programowa opiera się na modelowaniu 
obiektowym głównie w strukturze szkieletowej jako integralnej części środowiska 
operacyjnego. Ograniczenia projektanta oprogramowania nakładane przez architek- 
turę wynikają z użycia interfejsów i struktury oprogramowania, a nie ze sposobu 
implementacji realizowanych funkcji. Dzięki temu innowacyjny projekt, lub jego 
część, może być wielokrotnie wykorzystany w różnych implementacjach. Taka ar- 
chitektura wyznacza zasady funkcjonowania systemu otwartego. Specyficzne wy- 
magania implementacyjne mogą rozszerzać ten zbiór zasad, zwiększając możliwości 
wielokrotnego wykorzystania pewnych części oprogramowania wewnątrz i pomię- 
dzy domenami. Interfejsy i zasady, które definiują zgodność z architekturą SCA, są 
integralną częścią specyfikacji. Wybrano je w celu zwiększenia możliwości przeno- 
szenia, współpracy i konfiguracji oprogramowania oraz sprzętu, pozwalając nabyw- 
cy na elastyczne adresowanie wymagań i ograniczeń domeny [6]. 

Do graficznej reprezentacji interfejsów, układów, użytych przypadków i dia- 
gramów współpracy architektury SCA jest wykorzystywany zunifikowany język 
modelowania UML (Unified Modelling Language), określony przez zespół OMG 
(Object Management Group). Do definiowania interfejsów SCA jest używany język 
definicji interfejsu IDL (Interface Definition Language), również określony przez 
OMG. Jest to niezależny język programowania i może być kompilowany na przykład 
w językach C++ i Java. Oprócz tego wykorzystuje się język XML (Extensible Markup 
Language). Zastosowano go w profilu domen do identyfikacji właściwości oraz 
lokalizacji urządzeń i komponentów oprogramowania. 

Architekturę oprogramowania terminala ruchomego przedstawia rysunek 3. [6]. 
Do głównych korzyści tej architektury należy wykorzystanie komercyjnych protoko- 
łów, oddzielenie aplikacji szkieletowych od innych aplikacji poprzez wiele warstw 
otwartej, komercyjnej infrastruktury programowej oraz wykorzystanie architektury 
CORBA w celu zapewnienia możliwości wielokrotnego wykorzystania, skalowalności 
i przenoszenia aplikacji. 

Jak widać na rysunku 3., architektura oprogramowania ma strukturę warstwową 
[2, 6], najniższą jest warstwa magistrali. Architektura programowa jest zdolna funkcjo- 
nować w oparciu o różne komercyjne architektury magistrali, środowisko operacyjne 
obsługuje bowiem mechanizm transportowy, który może zawierać mechanizmy 
detekcji i korekcji błędów na poziomie obsługi magistrali. Przykładowymi magistra- 
lami możliwymi do zastosowania są magistrale: PCI, CompactPCI, Firewire i Ethernet. 
Środowisko operacyjne nie wyklucza wykorzystania innych magistrali [6]. 
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Rys. 3. Architektura oprogramowania terminala ruchomego w technologii SDR 


Źródło: SCA V3.0, Software Communications Architecture Specification, Joint Tactical Radio 
System (JTRS) Joint Program Office, August 2004. 


Kolejną warstwą jest warstwa sieci i usług interfejsów szeregowych. Archi- 
tektura programowa wykorzystuje również komercyjne programy do obsługi wielu 
interfejsów szeregowych i sieciowych. Możliwymi interfejsami sieciowymi i szerego- 
wymi zastosowanymi w architekturze SCA mogą być: RS232, RS422, RS423, RS485, 
Ethernet i IEEE 802.x [6]. 
Dalej zostaną przedstawione pozostałe warstwy oprogramowania. 


Warstwa systemu operacyjnego 


Architektura programowa zawiera wbudowane funkcje systemu operacyjnego 
czasu rzeczywistego w celu zapewnienia wielowątkowej obsługi aplikacji. Architektura 
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ta wymaga standardowego interfejsu systemu operacyjnego dla usług systemowych 
w celu ułatwienia przenoszenia aplikacji. Przewiduje wykorzystanie systemu opera- 
cyjnego POSIX (Portable Operating System Interface) [2, 6], który jest akceptowanym 
standardem przemysłowym. System operacyjny POSIX i jego rozszerzenia czasu 
rzeczywistego są kompatybilne z wymaganiami obsługi architektury CORBA [2, 6]. 


Warstwa struktury szkieletowej 


Warstwa struktury szkieletowej składa się z bazowych interfejsów aplikacji, 
które mogą być wykorzystane przez wszystkie aplikacje. Zawiera też szkieletowe 
interfejsy sterujące, które zapewniają sterowanie w systemie. Ponadto zawiera inter- 
fejsy usług szkieletowych, które obsługują zarówno aplikacje struktury szkieletowej, 
jak i pozostałe aplikacje. Składnikiem warstwy struktury szkieletowej jest również 
domena profili opisująca własności urządzeń i oprogramowania w systemie [6]. 


Oprogramowanie CORBA 


Oprogramowanie CORBA jest strukturą wieloplatformową, która może być 
wykorzystana do standardowych operacji typu klient/serwer, gdy używamy przetwa- 
rzania rozproszonego [6]. 


Warstwa aplikacji 


Aplikacje wykonują funkcje komunikacji z użytkownikiem i zawierają prze- 
twarzanie sygnałów na poziomach warstw modemu, łącza oraz sieci. Realizują rów- 
nież międzysieciowy dobór drogi i zewnętrzny dostęp I/O. Aplikacje korzystają 
z interfejsów i usług struktury szkieletowej. Bezpośredni dostęp aplikacji do syste- 
mu operacyjnego jest ograniczony przez usługi opisane w specyfikacji profilu POSIX. 
Funkcje sieciowe, które mogą być implementowane poniżej warstwy aplikacji, takie 
jak komercyjna warstwa IP, nie są ograniczone profilem POSIX, jeśli są umieszczone 
w przestrzeni jądra systemu operacyjnego [6]. 


Adaptery 


Adaptery są urządzeniami i zasobami programowymi wykorzystywanymi 
do obsługi składników struktury oprogramowania niezgodnych z oprogramowaniem 
CORBA. Adaptery są używane do realizacji translacji informacji pomiędzy zasoba- 
mi programowymi lub sprzętowymi zgodnymi ze standardem CORBA i zasobami 
niepracującymi według tego standardu [6]. 
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PLATFORMA SPRZETOWA 
DO REALIZACJI RADIA PROGRAMOWALNEGO 


Przyktadem platformy sprzetowej do realizacji radia programowalnego jest 
Small Form Factor SDR firmy Lyrtech RD [7]. Składa sie ona z trzech głównych 
bloków zrealizowanych na trzech połączonych ze sobą płytkach. Blokami tymi sa: 
moduł radiowy (RF), moduł konwersji danych oraz moduł cyfrowego przetwarzania. 
Moduł radiowy został wyposażony w dwie anteny, dzięki którym można nadawać 
i odbierać sygnał radiowy. Widok całego urządzenia przedstawia rysunek 4. 


Moduł RF 


Moduł 
cyfrowego 
przetwarzania 


konwersji 
danych 


Rys. 4. Widok przykładowej platformy sprzętowej radia programowalnego [7] 


Źródło: Small Form Factor SDR Evaluation Module/Development Platform User's Guide, 
Lyrtech 2010. 


Platforma jest urządzeniem o niewielkich rozmiarach zawierającym wszystkie 
komponenty sprzętowe niezbędne od realizacji urządzenia nadawczo-odbiorczego w tech- 
nologii radia programowalnego. Schemat blokowy platformy sprzętowej został przed- 
stawiony na rysunku 5. (Digital processing module). Składa się on z dwóch głównych 
elementów: matrycy FPGA Virtex-4 firmy Xilinx i procesora TMS320DM6446 SoC 
firmy Texas Instruments. Procesor zawiera w jednej obudowie układu scalonego 
procesor sygnałowy DSP (Digital Signal Processor) i procesor ogólnego przeznaczenia 
GPP (General Purpose Processor). Procesor może korzystać z pamięci SDRAM DDR2 
o pojemności 128 MB i pamięci flash o pojemności 1 GB. Moduł cyfrowego prze- 
twarzania zawiera również interfejsy: RS232, USB i Ethernet. Zawiera też kodek 
stereo, dzięki któremu możliwe jest podłączenie słuchawek, mikrofonu i zewnętrzne- 
go źródła dźwięku. Poza tym zawiera przyciski, których funkcje można programować 
oraz diody LED informujące o stanie pracy elementów modułu. Moduł konwersji 
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danych będący drugim modułem platformy sprzętowej połączony jest z modułem 
cyfrowego przetwarzania specjalnym złączem (Data conversion module expansion 
connector). Zawiera matrycę FPGA Virtex-4, dwukanałowy 16-bitowy przetwornik 
cyfrowo-analogowy DAC5687, dwa 14-bitowe przetworniki analogowo-cyfrowe 
ADC5500 oraz wzmacniacze o programowanej wartości wzmocnienia. Moduł radiowy 
w wersji low-band może pracować w paśmie 200 MHz-1 GHz z szerokością kanału 
5 MHz lub 20 MHz. Wersja high-band modułu radiowego może pracować z takimi 
samymi szerokościami kanału w paśmie 1.6-2.2 GHz. Szerokość kanału i częstotliwości 
— zarówno dla kierunku nadawania, jak i odbioru — mogą być zmieniane w sposób 
programowy. Obie wersje modułów radiowych zawierają bloki up-konwerterów prze- 
noszących sygnał z pośredniej częstotliwości (30 MHz) na właściwą częstotliwość ra- 
diową, bloki down-konwerterów realizujących operację odwrotną i odpowiednie filtry. 
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RF in p— IF out f IF in |-— RF out 


Data conversion module 
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Rys. 5. Schemat blokowy przykładowej platformy sprzętowej radia programowalnego 
Źródło: Small Form Factor SDR Evaluation..., wyd. cyt. 


84 Zeszyty Naukowe AMW 


Technologia radia programowalnego w zastosowaniach wojskowych 


Przedstawiona platforma sprzetowa umozliwia uruchamianie i testowanie 
oprogramowania realizujacego nadajnik i odbiornik w technologii radia programo- 
walnego. Oprogramowanie napisane i skompilowane na komputerze klasy PC moze 
być wprowadzone do procesora i matrycy FPGA poprzez interfejs sieci Ethernet 
i uruchomione na sprzęcie, realizując nadajnik i odbiornik dla danego systemu łącz- 
ności radiowej. Możliwa jest programowa implementacja całego toru nadawczo- 
-odbiorczego z operacjami modulacji/demodulacji, kodowania/dekodowania kana- 
łowego i źródłowego, szyfracji/deszyfracji. Dzięki dużej szerokości kanału (5 MHz 
lub 20 MHz) oraz dużej mocy obliczeniowej możliwa jest realizacja interfejsów 
radiowych DS-CDMA, FH-CDMA i OFDM stosowanych w nowoczesnych syste- 
mach łączności wojskowych i cywilnych. 


PODSUMOWANIE 


Technologia radia programowalnego umożliwia szybką zmianę właściwości 
sprzętu i jego adaptację do aktualnych zastosowań. Szeroki zakres rozwiązań syste- 
mowych w zastosowaniach wojskowych i cywilnych powodował konieczność wy- 
korzystania dużej liczby różnorodnego sprzętu umożliwiającego łączność radiową. 
Technologia SDR umożliwia użycie tego samego sprzętu, z odpowiednim oprogra- 
mowaniem, w różnych, często odmiennych zastosowaniach, zarówno wojskowych, 
jak i cywilnych. Dodatkowo możliwość łatwego, programowego upgrade’u właści- 
wości sprzętu pozwala dłużej wykorzystywać urządzenia. Programowa architektura 
oprogramowania (SCA), opisana w artykule, wykorzystując sprawdzone i uniwer- 
salne rozwiązania, umożliwia łatwą przenośność oprogramowania, które może być 
instalowane i uruchamiane na sprzęcie zgodnym z tą architekturą, wyprodukowa- 
nym przez dowolnego producenta. 

Oprogramowanie testowane i uruchomione na platformie SFF SDR w zapre- 
zentowanej wersji laboratoryjnej może być przeniesione i uruchomione na podob- 
nym urządzeniu w wersji wojskowej w postaci radiostacji dorecznej lub przewoznej 
do zamontowania w pojeździe. 
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SOFWARE DEFINED RADIO TECHNOLOGY 


IN MILITARY APPLICATIONS 


ABSTRACT 


Software Defined Radio (SDR) is a modem solution used to develop of devices imple- 


mented in various types of radio systems, both civilian and military. The paper presents some 
issues concerned with the implementation of the concept of the SDR. It describes the software 
and hardware platform for such a solution. The paper presents the structure of the hardware plat- 
form used to develop a programmable radio. It also includes software communication architecture 
for military applications called the Joint Tactical Radio System (JTRS). 
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